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INVENTORS: John R. Hind, Yongcheng Li, Yih-Shin Tan 

Machine-Oriented Extensible Document Representation and 

Interchange Notation 



BACKGROUND OF THE INVENTION 

Related Inventions 

The present invention is related to U. S. Patent , titled "Array-Based Extensible 

Document Storage Format" (serial number 09/ ), referred to herein as the "first related 

invention", and U. S. Patent , titled "ffigh-Performance Extensible Document 

Transformation" (serial number 09/ ), filed concurrently herewith. These related 

inventions are commonly assigned to International Business Machines Corporation (IBM), and 
are hereby incorporated herein by reference. 
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Field of the Invention 

The present invention relates to a computer system, and deals more particularly with a 
machine-oriented notation for representation and interchange of extensible documents, as weU as 
a method, system, and computer program product for operating upon (e.g. parsing, and storing 
documents in) this notation. The notation may be used as an alternative to the Extensible Markup 
Language (XML), capturing the same information in a more efficient manner. 



nMrription of the Related Art 

Business and consumer use of distributed computing, also commonly referred to as 
networic computing, has gained tremendous popularity in recent years. In this computing model, 
the data and/or programs to be used to perform a particular computing task typicaUy reside on 
(i.e. are "distributed" among) more than one computer, where these multiple computers are 
connected by a networic of some type. The Internet, and the part of the Internet known as the 
World Wide Wd) (hereinafter, "Web", are well-known examples of this type of environment 
wherein the multiple computers are connected using a public network. Other types of network 
environments in which distributed computing may be used include intranets, which are typically 
private networks accessible to a restricted set of users (such as employees of a corporation), and 
extranets (e.g., a corporate network which is accessible to other users than just the employees of 
the company which owns and/or manages the network, such as the company's business partners). 



The Extensible Markup Language ("XML") is becoming the de facto standard format for 
RSW9-2000-0069-US1 -2- 



representing and exchanging information in these environments. XML is a tag language, which is 
a language that uses specially-designated constructs referred to as 'tags" to delimit (or "mark 
up") information. In the general case, a tag is a keyword that identifies what the data is which is 
associated with the tag, and is typically composed of a character string enclosed in special 
5 characters. "Special characters" means characters other than letters and numbers, which are 

defined and reserved for use with tags. Special characters are used so that a parser processing the 
data stream will recognize that this a tag. A tag is normally inserted preceding its associated data: 
a corresponding tag may also be inserted following the data, to clearly identify where that data 
ends. As an example of using tags in XML, the syntax "<email>" could be used as a tag to 
IS indicate that the character string appearing in the data stream after this tag is to be treated as an 
^ e-mail address; the syntax "</email>" would then be inserted after the character string, to delimit 
where the e- mail character string ends. 

m The syntax of XML is extensible and flexible, and allows document developers to create 

^ tags to convey an explicit nested tree document structure (where the structure is determined fi-om 

. — ^ 

the relationship among the tags in a particular document). Furthermore, document developers can 
define their own tags which may have application-specific semantics. Because of this 
extensibility, XML documents may be used to specify many difiFerent types of information, for use 
in a virtually unlimited number of contexts. It is this extensibility and flexibility which is, in large 
part, responsible for the popularity of XML. (A number of XML derivative notations have been 
20 defined, and continue to be defined, for particular purposes. "VoiceXML" is an example of one 
such derivative. References herein to "XML" are intended to include XML derivatives and 
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semantically similar notations such as derivatives of the Standard Generalized Markup Language, 
or "SGML", from which XML was derived. Refer to ISO 8879, "Standard Generalized Markup 
Language (SGML)", (1986) for more information on SGML. Refer to '^Extensible Markup 
Language (XML), W3C Recommendation 10-February*1998" which is available on the World 
Wide Web at http://www.w3.org/TR/1998/REC-xmi-19980210, for more information on XML.) 

Although XML is an excellent data format, the posing, manipulation, and transformation 
of XML documents involves a considerable amount of overhead. Figure 1 provides a simple 
example of prior-art XML syntax for a document 100 that may be used for specifying names (for 
example, names of the employees of a corporation, the customers of a business, etc.). In this 
example, a <LAST_NAME> tag pair 105, 1 10 is used to represent information for a last name, 
and a <FIRST_NAME> tag pair 115, 120 is used to represent information for a first name. The 
data content vMues for the last name and first name then appear (as a string, in this case) between 
the opening and closing tags. The <MIDDLE_INITIAL !> tag 125 in this case uses a short-hand 
empty tag format where the tag name of a tag having no data content is followed by a closing tag 
symbol "/>". XML tags may also contain attribute names and attribute values, as shown by the 
'SUFFIX - "Jr."' attribute 135 specified within the opening <LAST_NAME> tag 130. As can be 
seen upon inspection of this document 100, the entire data content of this example comprises 22 
characters. The tag syntax, however, adds another 201 printable characters (not including tabs, 
line returns, blanks, etc.), or approximately 90 percent of the total document file size. In the 
general case, the overhead in tenns of characters used for the tag syntax could be even higher, as 
the tag names might be even longer than those shown. In addition, the data content specified in 
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this example as an attribute (shown at 135) could alternatively be represented as an element within 
its own opening and closing tag pair, leading to an even greater amount of tag-related overhead. 

The extensible tag syntax enables an XML document to be easily human-readable, as the 
tag names can be designed to convey the semantic meaning of the associated data values and the 
overall relationship among the elements of the data. For example, in Fig. 1 the tag names and 
structure explicitly show that a name includes a last name, a first name, and a middle initial. This 
human-friendly, well- structured format enables a human being to quickly look through an 
arbitrary XML document and understand the data and its meaning. However, it will take a 
computer quite a lot of effort to understand the data and do useful things with it. The raw 
content of most XML documents will never be seen by a human: instead, what the end user sees 
is typically created using a rendering application (such as an XML parser within a browser) which 
strips out the tags and displays only the embedded data content. The added overhead of the 
human-friendly tag syntax therefore leads to unnecessary inefficiencies in processmg and storing 
structured documents when the documents will only be "seen" by a computer program, such as 
for those documents which are formatted for interchange between computer programs for 
business-to-business ("B2B") or business-to-consumer ("B2C") use. This is especially true when 
the XML document is destined for processing on a high-volume transaction server, where none of 
the processing steps is likely to require a human to see or understand the document tags. 

Accordingly, what is needed is a machine-oriented notation that improves the processing 
time for arbitrarily-structured documents and reduces the storage requirements and transmission 
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costs of data interchange, while still retaining the extensibility and flexibility of XML and while 
conveying equivalent content and semantic infonnation. Techniques for converting documents 
created in XML to this alternative notation, and optionally for converting from the alternative 
notation back to XML, are preferably provided to enable XML to be surfaced to humans in its 
current, human-friendly format if necessary. 

SUMMARY OF THE INVENTION 

An object of the present invention is to pro\ide a machine-oriented notation for use as an 
XML alternative, where this machine-oriented notation improves the processing time for 
aibitrarily-structured documents and reduces the storage requirements and transmission costs of 
data interchange while still retaining the extensibility and flexibility of XML and while conveying 
eqmvalent content and semantic information. 

It is another object of the present invention to provide a technique for converting 
documents created in XML to this dtemative notation. 

Another object of the present invention is to provide a technique for converting from the 
alternative notation back to XML. 

It is also an object of the present invention to provide a notation which can be used to 
reduce the processing overhead, storage reqmrements, and/or transmission costs incurred when 
using XML or other similar notations. 
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Other objects and advantages of the present invention will be set forth in part in the 
description and in the drawings which follow and, in part, will be obvious from the description or 
may be learned by practice of the invention, 

5 To achieve the foregoing objects, and in accordance with the purpose of the invention as 

broadly described herein, the present invention provides a machine-oriented notation for 
representation and interchange of extensible documents, as well as a method, system, and 
computer program product for operating upon (e.g. parsing, and storing documents in) this 
S notation. In the preferred embodiment, a document encoded in this notation resides on one or 
p more computer-readable media and comprises: a node count representing a count of nodes in the 
5 document; a node specification for each of the nodes; and a data bufifer containing attribute names 
r and attribute values referenced from attribute lists (when present) and node values referenced 
m from node value specifications. Each of the node specifications comprises: a node name; a child 
H list specifying index values of zero or more nodes which are children of the node; optionally, an 
B attribute list specifying zero or more (attribute name, attribute value) pair references for attributes 
of the node; and a node value specification, which is empty if the node has no value. 

In one aspect, each (attribute name, attribute value) pair reference specifies a starting 
name position, a name length, a starting value position, and a value length. The starting name 
position and starting value position are preferably relative to a beginning of the data buffer or to a 
20 beginning of the document. In this aspect, the node value specification preferably specifies a 
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starting value position and a value length, where this starting value position may be relative to a 
beginning of the data buffer or to a beginning of the document. 

In another aspect, each (attribute name, attribute value) pair reference specifies a starting 
name position, an ending name position, a starting value position, and an ending value position. 
In this aspect, the node value specification preferably specifies a starting value position and an 
ending vdue position. 



The present invention also provides a technique for encoding a document in an extensible 
i machine-oriented structured notation, comprising: encoding a node count representing a count of 
I nodes m the document; encoding a node specification for each of the nodes; encoding a data 

buffer comaimng attribute names and attribute vahies referenced firom attribute fis^^ 
T present) and node values referenced from node value specifications; and storing the encoded node 
i count, the encoded node specifications, and the encoded data buffer as the encoded document in 
S memory or writing the encoded document to one or more storage media. Encoding the node 
^' specifications fiirther comprises: encoding a node name; encodmg a child list specifying index 
1 5 values of zero or more nodes which are children of the node; optionally, encoding an attribute list 

specifying zero or more (attribute name, attribute value) pair references for attributes of the node; 

and encoding a node value specification, which is empty if the node has no value. 

The present invention also provides a technique for processing a document encoded in an 
extensible machine-oriented structured notation, comprising: parsing the document and 
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using the parsed document as input for the processing. Parsing the document further comprises: 
parsing a node count representing a count of nodes in the document; parsing a node specification 
for each of the nodes; and parsing a data buffer containing attribute nsmes and attribute values 
referenced fi-om the attribute lists and node values referenced firom the node value specifications. 
Parsing the node specification fijrther comprises: parsing a node name; parsing a child list 
specifying index values of zero or more nodes which are children of the node; parsing an attribute 
list specifying zero or more (attribute name, attribute value) pair references for attributes of the 
node; and parsing a node value specification, which is empty if the node has no value. 

The present invention fiirther provides a technique for converting an input document 
encoded in an extensible human-fiiendly extensible markup language ("XML") to an output 
document encoded in a machme-oriented extensible markup language ("mXML"), comprising: 
creating a document tree representation of the input document; obtaining a node count 
representing a count of nodes in the document tree representation; writing the node count to an 
mXML buffer; traversing each node in the document tree representation and generating a 
corresponding node specification in the mXML buffer; generating a data buffer contauiing 
attribute names and attribute values refetenced fi-om attribute lists and node values referenced 
fi-om node vahie specifications; and appending the data buffw to the mXML buffer to form the 
output document. Traversing each node and generating the corresponding node specification 
fiirther comprises: generating a node name; generating an attribute list specifying zero or more 
(attribute name, attribute vahie) pair references for attributes of the node; generating a child list 
specifying index values of zero or more nodes which are children of the node; and generating a 
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node value specification, which is empty if the node has no value. 

In one aspect of this technique, generating each (attribute name, attribute value) pair 
reference preferably further comprises generating a starting name position, a name length, a 
starting value position, and a value length. The starting name position and starting value position 
are preferably relative to a beginning of the data buffer, or to a beginning of the output document. 
Also in this technique, the node value specification preferably specifies a starting value position 
and a value length. This starting value position is preferably relative to a beginning of the data 
buffer or to a beginning of the document. 

In another aspect of this technique, generating each (attribute name, attribute value) pair 
reference preferably further comprises generating a starting name position, an ending name 
position, a starting value position, and an ending value position. The node value specification may 
be specified as a starting value position and an ending value position. 

The present invention will now be described with reference to the following drawings, in 
which like reference numbers denote the same element throughout. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 illustrates a simple example of an XML document using the XML notation of the 
prior art; 
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Figure 2 is a block diagram of a computer workstation enviromnent in which the present 
invention may be practiced; 

Figure 3 is a diagram of a networked computing environment in which the present 
invention may be practiced; 

Figures 4A through 4C ilhisti-ate a simple structured document created in existing XML 
notation, a tree structure representing the structure and data content of this prior art XML 
document, and an equivalent structured document represented in mXML notation according to a 
preferred embodiment of the present invention, respectively; 

Figure 5 provides a flowchart which sets forth a preferred embodiment of the logic which 
may be used to parse an mXML document, according to the present invention; 

Figure 6 provides a flowchart which sets forth the logic which may be used to convert an 
XML document to an mXML document, according to a preferred embodiment of the present 
invention; and 

Figure 7 provides a flowchart which sets forth the logic which may be used to convert an 
mXML document to an XML document, according to a preferred embodiment of the present 
invention. 
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DESCRIPTION OF THE PREFERRED EMBODIMENT 

Fig. 2 illustrates a representative workstation hardware environment in which the present 
invention may be practiced. The environment of Fig. 2 comprises a representative single user 
computer workstation 210, such as a personal computer, mcluding related peripheral devices. 
The workstation 210 includes a microprocessor 212 and a bus 214 employed to connect and 
enable communication between the microprocessor 212 and the components of the workstation 
210 in accordance with known techniques. The workstation 210 typically includes a user 
interfece adapter 216, which connects the microprocessor 212 via the bus 214 to one or more 
interface devices, such as a keyboard 218, mouse 220, and/or other interface devices 222, which 
can be any user interface device, such as a touch sensitive screen, digitized entry pad, etc. The 
bus 214 also connects a display device 224, such as an LCD screen or monitor, to the 
microprocessor 212 via a display adapter 226. The bus 214 also connects the microprocessor 212 
to memory 228 and long-term storage 230 which can include a hard drive, diskette drive, tape 
drive, etc. 

The workstation 210 may communicate with other computers or networks of computers, 
for example via a communications channel or modem 232. Alternatively, the workstation 210 
may communicate using a wireless interface at 232, such as a CDPD (ceMar digital packet data) 
card. The workstation 210 may be associated with such other computers in a LAN or a wide area 
network (WAN), or the woricstation 210 can be a client in a client/server arrangement with 
another computer, etc. All of these configurations, as well as the appropriate communications 
hardware and software, are known in the art. 
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The present invention may operate on a server or mainframe (referred to hereinafter as a 
server, for ease of reference), rather than on a workstation. The hardware environment of a 
server is well known in the art. Or, the present invention may operate on other computing devices 
such as personal digital assistants (PDAs), portable computing devices, etc. The documents 
created through use of the present invention may be stored on permanent or removable storage 
media used by a computing device, and/or may be transmitted between such a device and a server, 
or between a server and another server, where these types of devices may be connected by a 
network. 

Fig. 3 illustrates a data processing network 240 in which the present invention may be 
practiced. The data processing network 240 may include a plurality of individual networks, such 
as wireless network 242 and network 244, each of which may include a plurality of individual 
workstations 210. Additionally, as those skilled in the art will appreciate, one or more LANs may 
be included (not shown), where a LAN may comprise a plurality of intelligent workstations 
coupled to a host processor. 

Still referring to Fig. 3, the networks 242 and 244 may also inckide mainframe computers 
or servers, such as a gateway computer 246 or application server 247 (which may access a data 
repository 248). A gateway computer 246 serves as a point of entry into each network 244. The 
gateway 246 may be preferably coupled to another network 242 by means of a communications 
link 250a. The gateway 246 may also be directly coupled to one or more workstations 210 using 
a communications link 250b, 250c. The gateway computer 246 may be implemented utilizing an 
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Enterprise Systems Architecture/370 available from IBM, an Enterprise Systems Architecture/390 
computer, etc. Depending on the application, a midrange computer, such as an AppUcation 
System/400 (also known as an AS/400) may be employed. ("Enterprise Systems 
Architecture/370" is a trademark of fflM; "Enterprise Systems Architecture/390", "Application 
System/400", and "AS/400" are registered trademarks of ffiM.) These are merely representative 
types of computra-s wth which the present invention may be used. 

The gateway computer 246 may also be coupled 249 to a storage device (such as data 
repository 248). Further, the gateway 246 may be directly or indirectly coupled to one or more 
workstations 210, and servers such as gateway 246 and appUcation server 247 may be coupled to 
other servere such as server 243. 

Those skilled in the art will appreciate that the gateway computer 246 may be located a 
great geographic distance from the network 242, and similarly, the workstations 210 may be 
located a substantial distance from the networks 242 and 244. For example, the network 242 may 
be located in California, while the gateway 246 may be located in Texas, and one or more of the 
workstations 210 may be located in New Yoric. The workstations 210 may connect to the 
wireless network 242 using a networking protocol such as the Transmission Control 
Protocol/Intemet Protocol ("TCP/IP") over a number of alternative connection media, such as 
ceMar phone, radio frequency networks, satelUte networks, etc. The wireless network 242 
preferably connects to the gateway 246 using a network connection 250a such as TCP or UDP 
(User Datagram Protocol) over IP, X.25, Frame Relay, ISDN (Integrated Services Digital 
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Network), PSTN (Public Switched Telephone Network), etc. The workstations 210 may 
alternatively connect directly to the gateway 246 using dial connections 250b or 250c. Further, 
the wireless network 242 and network 244 may connect to one or more other networks (not 
shown), in an analogous manner to that depicted in Fig. 3. 

Software programming code which embodies the present invention is typically accessed by 
the microprocessor 212 (for example, of the workstation 210, server 243, gateway 246, and/or 
server 247) from long-term storage media 230 of some type, such as a CD-ROM drive or hard 
drive. The software programming code may be embodied on any of a variety of known media for 
use with a data processing system, such as a diskette, hard drive, or CD-ROM. The code may be 
distributed on such media, or may be distributed to users from the memory of storage of one 
computer system over a network of some type to other computer systems for use by users of such 
other systems. Altemativdy, the programming code may be embodied in the memory 228, and 
accessed by the microprocessor 212 using the bus 214. The techniques and methods for 
embodying software programming code in memory, on physical media, and/or distributing 
software code via networks are well known and will not be further discussed herein. 

The present invention may be used on a cUent computer or server in a networking 
environm«it, or on a standalone workstation (for example, to prepare a file or to process a file 
which has been received over a network connection, via a removable storage medium, etc.). 
(Note that references herein to client and server devices are for purposes of illustration and not of 
limitation: the present invention may also be used advantageously with other networking models.) 

RSW9-2000-0069-US1 -15- 



When used in a networking environment, the client and server devices may be connected using a 
"wireline" connection or a 'Nvireless" connection. Wireline connections are those that use 
physical media such as cables and telephone Imes, whereas wireless connections use media such as 
satellite links, radio frequency waves, and infrared waves. Many connection techniques can be 
used with these various media, such as: using the computer's modem to establish a connection 
over a telephone line; using a LAN card such as Token Ring or Ethernet; using a cellular modem 
to establish a wireless connection; etc. The workstation or client computer may be any type of 
computer processor, including laptop, handheld or mobile computers; vehicle-mounted devices; 
desktop computers; mainframe computers; etc., having processing (and, optionally, 
communication) capabilities. The server, simUarly, can be one of any number of different types of 
computer which have processing and communication capabilities. These techniques are well 
known in the art, and the hardware devices and software which enable their use are readily 
available. 

In the preferred embodiment, the present invention is implemented in computer software. 
The implementation of this software may operate as one or more modules (also referred to as 
code subroutines, or "objects" in object-oriented programming) of one or more computer 
programs. 

The present invention provides a machine-oriented notation for structured data 
representation and interchange that may be used as an alternative to XML. The notation is 
designed to be significantly more compact than XML, while still conveying the content and 
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semantics of the data and the structure of the document in a manner that is equivalent to existing 
XML. Thus, the mXML notation benefits firom the same extensibihty and flexibility which are key 
to the wide acceptance of XML. With more and more application programs being written to 
operate upon XML documents, the improvements yielded by the mXML notation will have a 
5 significant impact. An existing XML document may be converted to this machine-oriented 

notation, which is referred to herein as "mXML'' for "machine-oriented XML". Or, documents 
may be created directly in mXML as an alternative to creation in XML. In the general case, a 
document represented using the mXML notation can be processed much more efficiently than 
when using the existing human-ffiendly XML notation, requires much less storage space, and has 
W a significantly lower transmission cost for data interchange (for example, fi-om one computing 
^ device to another across a network). XML documents can be converted to mXML using 
U techniques of the present invention, as will be described in more detail herein. For those cases 
r where it is necessary or desirable for a human to see the document in the human-fiiendly form (for 
ffl example, for directly editing the document fi-om its source file), a document represented in 
mXML can be easily converted to XML using techniques of the present invention. 

The present invention also provides a method, system, and computer program product for 
operating upon (e.g. parsing, and storing documents in) this notation. The present invention also 
defines a technique for converting existing XML documents to mXML, and for converting 
mXML documents to XML. 



20 



The preferred embodiment of the present invention vrill now be described in more detail 
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with reference to Figs. 4 through 7. 



Fig. 4A illustrates a simple structured document 400 which is represented in the existing 
XML notation. This document contmns 6 elements which are organized in a 3-level hierarchy. 
The node having element name "root element" 402 is the root node, being at the highest level of 

5 the hierarchy. This node has 2 child nodes, having element names 'level one^elementl" 410 and 
'1evel_one_element2" 420. Node "level one^elementF' 410 also has 2 child nodes, which are the 
nodes having element names 'level^two elementir' 412 and '1evel_two_elementl2" 414, and 
node "level_two_element2" 420 has a single child node having element name 

5 "ievel_two_element2 1" 422. A tree structure 430 representing document 400 is shown in Fig. 
W 4B, where the tags for the 6 elements are depicted inside rectangular shapes representing nodes of 
the tree and the data content corresponding to each node is shown inside an ellipse. This 

IS: ? 

interpretation of an XML document 400 and its corresponding tree structure 430 are well known 

o 

m in the art, 

^ Fig. 4C illustrates a structured document 460 using a preferred embodiment of the syntax 

1 5 of the mXML notation, representing the same information as XML document 400 of Fig, 4A (and 
having the same tree structure as that shown at 430 in Fig, 4B). This mXML document 460 uses 
216 characters, whereas the equivalent XML document 400 uses 273 characters. (In addition, it 
should be noted that XML document 400 also includes approximately 23 additional non-printing 
characters (such as spaces, tabs, and line returns), for a total of 296 characters.) There may be 
20 isolated instances where use of mXML will increase the number of bytes required to store a 
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structured document, as compared to the existing XML notation. However, this increase in 
character count is expected to be extremely rare in actual practice, and will occur only when tag 
names are extremely short. It is therefore expected that the majority of XML documents will 
require less space when represented in mXML. 

The mXML notation is designed to represent an XML document in such a way that a 
computer can quickly and efficiently scan through the document, and can also manipulate it 
efficiently. Documents may therefore be created directly in, and used in, their mXML format. On 
the rare occasions when a human must see the document in a human-friendly form (for manual 
editing or other purposes, for example), a relatively small amount of overhead will be incurred to 
perform a conversion from mXML to XML. Documents which have been created in the existii^ 
XML syntax may be more efficiently processed and/or stored by converting them to mXML. 

The preferred embodiment of the mXML notation, as described herein, has been designed 
with the following consideratioiws: 

1) The data content is separated from the document structure, rather than being 
intermingled within the structure as in the existing XML notation. In the example of Fig. 4, the 
data content comprises the element values A, B, C, D, and E; the attribute names "id" and "name' 
(for the element shown at 410), and 'Id" and '*name" (for the element shown at 420); and the 
corresponding attribute values 1, 1, 2, and 2. Fig. 4A shows how this information is located 
throu^out the XML document 400 in the prior art. In Fig. 4C, on the other hand, these values 
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are stored at the end of the mXML document, beginmng at the position indicated with reference 
number 480. When a parser operates on a document (such as document 400 or 460), it is 
interested primarily m the document structure. The processing of the data content in an mXML 
document can therefore be delayed to the time when it is needed, and thus the separation of data 
structure and data content which is provided in mXML enables parsers to operate more 
efficiently. 

2) The document tree structure is stored explicitly in the document when using 
mXML, rather than requiring the parser to deduce the document structure using look-ahead 
techniques as is required when XML tags of the prior art are parsed. Thus, a parser operating on 
an mXML document does not need to learn how to construct the document tree, and a number of 
compute-intensive operations can therefore be eliminated. Instead, the mXML parser merely 
scans the mXML document and rebuilds the tree according to the explicit, akeady-stored 
information (as will be described in more detail below). 

3) Important information which is required for operation of the mXML parser is 
stored in advance within the mXML document, so that the parser can minimize its memory 
operations when constructing a corresponding document tree. In particular, the node count is 
precomputed and stored in the mXML document. According to the preferred embodiment of the 
mXML notation, this value is stored at the beginning of an mXML document. (In an alternative 
embodiment, the size of the data content is also precomputed and explicitly stored. In addition or 
instead, the starting location within the document of the data buffer may be explicitly stored if 
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desired, enabling direct access to the data buffer without requiring additional processing such as 
the backward scanning process described below with reference to Fig. 5,) Thus, the parser can 
allocate most of the memory it needs at the beginning of its operation, thereby reducing the 
number of computationally expensive memory allocation (and de-allocation) operations it must 
perform. Furthermore, the high cost of garbage collection operations that occur when memory is 
being allocated and de-allocated frequently can be minimized. 

A preferred syntax for mXML will now be described. It will be obvious to one of 
ordinary skill in the art, however, that alterations may be made to this preferred syntax without 
deviating from the inventive concepts disclosed herein. Several examples of such alterations will 
be described. 

As has been stated, an mXML document preferably begins with an integer count of the 
number of nodes or, equivalently, the number of tag names which are represented in the 
document. When converting an XML document into mXML, this count is easily determined by 
scanning for occurrence of the opening tag syntax. 

Preferably, the node count does not include opening comment tags, and comment text is 
preferably discarded during such a conversion as the comments are generally not useftil for the 
machine to which an mXML document is targeted. Other tags which are significant, on the other 
hand, such as a tag which identifies the Document Type Definition ('T)TD") to be used for a 
particular docimient, may be included in the mXML notation by searching for appropriate 
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keywords in such tags and preserving the located comment during a conversion from XML to 
mXML, A preferred technique for handling tags of this type is described in more detail below, 
prior to the discussion of Fig. 5. 

In the alternative embodiment where the data size is also explicitly stored in the document, 
this integer value preferably follows the node coimt, using a suitable delimiter such as a semi- 
colon. The integer data count in this alternative embodiment preferably includes the number of 
characters in each attribute name and each attribute value, and in each node's data value, as these 
items are all stored as the document's data buffer area (i.e. the end of the mXML document). 

One or more node specifications follows the node count. Each node specification is 
preferably enclosed in opening and closing delimiters, such as the parentheses which are used in 
the preferred embodiment. (Thus, it is not necessary to follow the node count with a separate 
delimiter.) Alternatively, another syntax could be used for opening and closing delimiters, such as 
opening and closing square brackets. Preferably, no spaces occur between the delimiters or 
tokens used in mXML, as shown in Fig. 4C. This enables minimizing the storage and 
transmission requirements. Thus, the node count is immediately followed by the first delimiting 
open parenthesis, which is immediately followed by the first node name, and so forth. 

The elements contained within a node specification according to the preferred embodiment 
of the mXML syntax will now be described. It should be noted that the order of these elements 
may be altered without deviating fi*om the inventive concepts disclosed herein. 
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The node specification of the preferred embodiment begins by explicitly recording the 
node name (i.e. its tag value). This name is then followed by a delimiter, which is a semi-colon in 
the preferred embodiment. A list of the node's child nodes follows this delimiter, and this child 
list is then followed by another occurrence of the deUmiter and a Ust of the node's attribute 
5 information. The attribute information is followed by the delimiter, which is followed by 

information that enables locating the node's data content. (Alternatively, the meaning of the 
delimiters used in the preferred embodiment can be changed, for example by using a comma in 
place of the semi-colon delimiters of the preferred embodiment and vice versa.) 

^ The information in the node specification will now be described in more detail with 

W reference to the example of Fig, 4. The node shown at 402 of Fig. 4A has 2 child nodes, shown 

at 410 and 420. The node shown at 410 is the second of the 6 nodes of the example, and the 
^ ' node shown at 420 is the fifl;h node. The preferred embodiment uses zero-based counting (except 
m for the node coimt which has been described), and thus the child list for the node shown at 402 is 
M specified using the syntax "1,4" (referring to the 2nd and 5th nodes) to indicate the relative 
H position of this node's children within the overaU tag sequence. The node shown at 410 has 2 
child nodes, shown at 412 and 414, which are the third and fourth nodes in the XML document. 
The child list for the node shown at 410 is therefore specified as "2,3", If a node has more than 2 
children, the child nodes are specified in the order they appear in the document and are separated 
(in the preferred embodiment) with commas. If a node has no children, as is the case with the 
20 node shown at 412, for example, then its child list is empty and the absence of children is 
indicated by the presence of 2 semi-colons in a row immediately following the node name. 
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The information for each attribute in the attribute list is also preferably delimited using a 
comma. Within each attribute's information, a period is preferably used as a delimiter. Referring 
to the example in Fig. 4 A, node Bl has 2 attributes. The first has the attribute name "id" and the 
attribute value "T\ Thus, the length of the attribute name is 2, and the length of the attribute 

5 value is 1 , Again using zero-based counting, the first attribute represented in the attribute list for 
the node shovra at 410 is therefore specified as "0.2.2, V% meaning that the name of the attribute is 
found in the data buffer starting at position 0 for a length of 2 characters, and the value is found 
starting at position 2 for a length of L As shown in Fig. 4C, the data buffer is preferably stored at 
the end of the mXML document. A parser can therefore avoid scanning these characters during 

1#J the parsing process when they are not needed. 

C The second of BTs attributes in this example has the name "name" and the value "1". The 

^ ' information for this second attribute is therefore specified using the syntax "3.4.7. 1", meaning that 
m the attribute's name is found in the data buffer starting at position 3 for a length of 4 characters 
H and its value is found starting at position 7 for a length of 1 . If a node has more than 2 attributes, 
W this dot-delimited syntax is used for each such attribute, and is separated fi*om the other attribute 
specifications for this node using commas as delimiters. As with the child list syntax, if a node has 
no attributes, the absence is indicated by specifying an empty attribute list. 

While the syntax used in the preferred embodiment refers to the data buffer using starting 
20 positions and length values, as described for the attribute names and values of the node at 412, in 
an alternative syntax the starting and ending positions within the data buffer may be used. Thus, 
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the specification for the first attribute of the node at 412 would be expressed as "0.1.2.2", 
meaning that the attribute name begins at position 0 and ends at position 1, and the attribute value 
begins and ends at position 2. Simiiariy, the specification fi-o the second attribute would be 
expressed as "3.6.7.T'. Use of length values, as selected for the syntax of the preferred 
5 embodiment, wiU in general require slightly less space than use of ending positions. 

The final entry in each node specification is the location of the node's data in the data 
buffer. As with the other entries which refer to the data buffer, this location is preferably specified 
as a starting position and a length (but may be specified as a starting and an ending position, in an 
m alternative embodraient), where the positions are specified as integer values. The integers are 
W preferably separated by commas, and use zero-based counting. If a node has no data, as in the 
^ case of the node at 402 in the example, them this final entry is left empty. The node at 410 has a 
r single-character data value in this example, and thus the final entry in this node's node 
5 specification is "8,1". As shown by the example syntax in Fig, 4C, the attribute names and values 
If are preferably intermingled in the mXML data buffer along with the data content of the nodes. 

1 5 Finally, the node specification for the last node (the node at 422, in the example of Fig. 

4C) is immediately followed by the contents ofthe data buffer. Because integer pointer values 
specify where each data item begins in this data buffer and its length, as described above, it is not 
necessary to use white space or other delimiters in the data buffer. 



Rather than specifying starting locations in terms of their offset fi-om the start of the data 
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buffer, they may alternatively be specified as offsets fi*om the start of the mXML document. This 
approach requires slightly more space, however, and requires that the data buffer offsets are 
recomputed each time the structural information increases or decreases in length. 

Thus, it can be seen that the structure of an mXML document is explicitly specified within 
5 the document. This information can be used to build a Document Object Model CT)0]Vf ') tree, if 
desired. The DOM tree can then be processed as in the prior art. Alternatively, the mXML 
document notation can be traversed directly, for example to locate information about a particular 
node, to determine the overall structure of the document, or to otherwise operate upon the 
a mXML document. The mXML document may be stored using the array-based extensible 
W docimient storage format described in the first related invention, resulting in fixrther processing 
™ efficiencies (as described therein) when operating on a document, (DOM is published as a 
^ Recommendation of the World Wide Web Consortium CW3C"), titled *T>ocument Object Model 
m (DOM) Level 1 Specification, Version 1 .0" (1998) and available on the Web at 
H http://www, w3.org/TR/REC-D0M-Level-l . '"DOM" is a trademark of Massachusetts Institute 
tS of Technology.) 

As examples of operations that may be performed directly on an mXML document, or 
from its array-based representation, it may be necessary to determine a node's children or perhaps 
its parent. The technique for explicitly specifying each node's children using a child list within an 
mXML document has been described above. A node's p^ent can be easily determined by 
20 traversing the child lists using the target node's sequence number. Suppose, for example, that it is 
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necessary to determine the parent of the node at 414. This node is the fourth node encountered in 
the node specifications of Fig. 4C, which corresponds to sequence number 3 when using 
zero-based counting. By locating the node specification which mcludes this sequence number m 
its child list, it can be seen that the node at 410 is the parent of the node at 414 (and also that the 
node at 414 is the second of 2 children). 

The XML notation includes a number of notational elements which ^e not strictly 
necessary for data-centered document specification. An XML subset referred to as "SML", for 
"Simple Markup Language", is currently under discussion in the technical community. This XML 
subset proposes use of a core set of XML syntax, and omission of features including attributes, 
processing instructions, etc. See, for example, a Web-published article entitled "SML: 
Sknplifying XML", which is written by Robert E. La Quey and is located at 
http://www.xml.eom/pub/1999/l 1/sml/mdex.html (published 1 1/24/99). The preferred mXML 
syntax which is described herein provides support for one core set of XML notational elements 
(although not identical to the core set proposed for SML), where the basic node types include 
elements and attributes. More complicated XML documents containing additional node types can 
be supported by extending this preferred mXML syntax, where those additional node types 
include comments, processing instructions, CD ATA, entity, entity reference, and document type 
nodes. In a preferred technique for specifying this extended mXML syntax, '^ext" nodes are 
added to an mXML document to refer to the actual node content, A node specification for a 
node type such as those just listed preferably occurs in-line within the mXML document, in the 
same relative location where it appears in a corresponding XML document. This node 
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specification preferably comprises a null value in place of the node name; a list pointing to one or 
more child nodes, as is used in the node specifications which have been described, except that the 
children are now text nodes; an empty attribute list; and a pair of special indicators as the node 
value specification. The starting position entry within the special indicator pair is used to denote 
which type of other node is being represented. For example, a value of -2 may represent a 
comment, while a value of -3 represents a processing instruction, and so forth. The length entry 
within the special indicator pah* is preferably set to -1 . The node specification for each of the 
child text nodes referenced fi-om the special child list preferably also uses a null name, and a null 
child list and attribute list. The value entry in this child text node then (1) points to a location 
within the data buffer where the node's content is stored (preferably as a character string 
representing all the significant content fi-om the source node), and (2) stores the length of this 
content. 

Furthermore, the SML syntax can be represented using an alternative embodiment of the 
present invention wherein the attribute information described for the preferred embodiment of 
mXML is omitted. 

Fig. 5 provides a flowchart which sets forth a preferred embodiment of the logic which 
may be used to parse an mXML document which uses the preferred mXML syntax, according to 
the present invention. This process begins at Block 500, where the size information (i.e. the 
number of nodes) for the document is determined by scanning the input. This size information is 
found as the first token of the mXML document, and will be an integer value. If the mXML 
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document is to be stored using the array-based representation disclosed in the first related 
invention, then this si2:e information is used to create arrays (as described in the specification of 
the first related invention) at Block 510. 

Block 520 then determines where the data buffer of the mXML document begins, 
5 Preferably, this comprises scanning the document in reverse order, fi^om the end of the document 
content until locating the first (that is, the last-occurring) closing parenthesis (or other delimiter 
that may be substituted for closing a node spmfication, if parentheses are not used for this 
purpose). As is well known in the art, there may be occasions when a symbol defined for use as a 
delimiter needs to be used simply as a character of data. An escape character may be defined to 
Iffi enable representing delimiters as their normal character value. Thus, this scan preferably accounts 
^ for this situation, and locates the first non-escaped closing parenthesis. The data buffer then 
^ ' begins at the next-sequential position of the mXML document, as illustrated at 480 in Fig. 4C. 
■m (Accounting for escaped characters will not be fiirther discussed with reference to Fig. 5. One of 
skill in the art Avill readily understand how this processing is to be handled.) 

1 5 Alternatively, when the location of the data buffer and/or the size of the data buffer is 

explicitly specified in the mXML document, as discussed earlier, the processing of Block 520 
comprises simply using the pre-stored information. 



The test in Block 530 asks whether all the elements in the document have been parsed. 
This test has a positive reailt when the next character is not an opening node specification 
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delimiter (i.e. an opening parenthesis, in the preferred embodiment). In this case, the parsing 
process of Fig. 5 is complete, and control returns to the invoking logic as shown at Block 590. 



When the elements in the document have not been completely parsed, the test in Block 
530 has a negative result and processing continues at Block 540, As indicated therein, the next 

5 element (that is, the next node) is to be parsed. This comprises positioning past the opening 

parenthesis for the node specification. Block 550 then parses the node's name firom the mXML 
document. In the preferred embodiment syntax, this comprises reading the characters until 
encountering a semi-colon delimiter. These characters then represent the node's name, and may 

ifl be stored or otherwise used. 

fl Block 560 parses the node's children list. The children list begins with the character after 

the semi-colon delimiter which follows the node's name, and continues up to the next semi-colon 
ffl delimiter. If the child list contains a comma, this indicates that there are multiple child nodes. (If 
U desired, the node specifications of the nodes in tWs children list may be parsed at this point by 
D using the child's node number fi-om the children list to position to the child's node specification 
1 5 and then recursively invoking the logic in Blocks 540 through 580, where a suitable alternative "at 
end" test is then used in Block 530.) 

Block 570 parses the node's attribute list. This attribute list follows the semi-colon 
delimiter used to end the children list, and continues up to the next semi-colon delimiter. The 
names and values of these attributes may be retrieved from the data buflfer, if desired, using the 
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data buffer starting position that was determined in Block 520 along with the individvial starting 
and length values specified as integers within the dotted notation used for the attribute list. If a 
comma is detected following the 4 integers in the dotted notation, this indicates the presence of an 
additional attribute that is then processed in the same manner. 

Block 580 then locates the node's value. This comprises obtaining the starting position 
and length values which follow the final semi-colon delimiter in the node specification, and which 
are separated fi-om one another with a comma delimiter. As with the attribute names and values 
in Block 570, the node value may be retrieved fi^om the data buffer using the pointer to the data 
buffer along with the node name's starting and length values. 

Control then returns to Block 530 to determine whether there are more node 
specifications to be parsed. 

There are at least 2 approaches that may be used to convert an XML document to an 
mXML document. In a first approach, a special parser may be written for this purpose, where the 
parser parses the XML syntax in a similar manner to existing XML parsers and then generates a 
corresponding document using mXML syntax. Using the teachings disclosed herein, it will be 
obvious how existing XML parsing techniques may be adapted for this purpose, (For example, a 
parser written in the Java programming language may be written to fire an event upon detecting 
the beginning and end of a node, an attribute name, an attribute value, etc., where programming 
code is written to handle those events by crating the appropriate mXML constructs.) In a 
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second approach, a preferred embodiment of which will now be described with reference to the 
logic in Fig. 6, a prior art XML parser is invoked to create a DOM tree. This DOM tree is then 
traversed, and the document information represented therein is then written out simply and 
efficiently, using mXML syntax. 

The conversion process depicted in Fig. 6 begins at Block 600, where an XML parser of 
the prior art is used to parse the XML document and create a corresponding DOM tree. Block 
610 then obtams a count of the nodes in this DOM tree, and writes this as an integer value into a 
buffer which is used to store the mXML document being created and will therefore be referred to 
as the "mXML buffer". A second buffer, referred to as the "data buffer", is then initialized, as is a 
counter that is used to point to a current location within this data buffo" (Block 620). 

The lo^c in Blocks 630 through 680 is then repeated as the DOM tree is traversed. 
Preferably, a depth-first traversal is used, to align with the ordering of nodes within the output 
mXML document as shown in Fig. 4C. Alternatively, the nodes in the output document may be 
created and specified therein in a breadth-first manner if desired. 

While the end of the DOM tree has not been reached, the test in Block 630 has a negative 
result and processing therefore continues at Block 640; otherwise, control transfers to Block 
690. At Block 640, the opening delimiter "(" is written into the mXML buffer to begin the node 
specification for the node currently being converted fi-om XML to mXML. Block 650 then 
obtains the node's name fi-om the DOM tree, and writes this into the next positions of the mXML 
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buffer, followed by a semi-colon delimiter. 



Block 660 creates the children list, and writes this to the next positions of the mXML 
buffer, again following the output characters with a semi-colon delimiter. If the DOM tree 
indicates that a node has no children, then only the delimiter is written out. Otherwise, the 
ordinaUty of the child nodes is determined, and the corresponding integer values for these nodes 
(preferably expressed in terms of zero-based counting) are written as a comma-separated list. 

Block 670 converts the node's attribute information, if any, and writes this to the mXML 
buffer, followed by a semi-colon delimiter. For each attribute of the current node that is located 
in the DOM tree, the attribute's name and value are written to the data buffer in successive 
locations. The position within the data buffer where the name begms, and its length, are written 
to the mXML buffer as the first two dot-separated integers of the attribute specification. The 
data buffer counter that was initialized at Block 610 is then incremented by the length of the 
attribute name. Similarly, the position within the data buffer where the attribute value begins, and 
its length, are written to the mXML buffer using the dot-separated notation (and after a dot that 
follows the attribute name's Imgth), and the data buffer counter i& incremented by the length of 
the attribute value. If this node has more than one attribute, a comma is written to the mXML 
buffer to delimit the dot-separated attribute specifications. 

After writing the semi-colon delimiter which marks the end of the attribute list, the node's 
data content is processed (Block 680). If the DOM tree incticates that the node has no data 
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content, then a closing parenthesis delimiter is written to the naXML buflfer and control returns to 
Block 630. Otherwise, the processing of Block 680 continues by writing the data content into the 
data buffer at the n^ available location. The starting position of this content is indicated by the 
current value of the data buflfer counter. This value is therefore written to the mXML buflfer, 
followed by a comma delimiter and the integer length of the content. The data buflfer counter is 
incremented by this length, and the closing parenthesis is written to the mXML buflfer. Control 
then transfers back to Block 630 to process the next node. 

Processing reaches Block 690 when all the nodes in the DOM tree have been processed. 
The corresponding node specifications have been converted to mXML, and are stored in the 
mXML buflfer. The attributes name and values, along with the data content for the nodes, are 
stored in the data buflfer. Block 690 thus appends the information from the data buflfer to the end 
of the mXML buffer. The mXML buffer now contains an mXML document such as that 
illustrated in Fig. 4C, corresponding to the input XML document such as that shown in Fig. 4A. 
This mXML document may now be processed, transmitted, or stored for later use as desired. (As 
an alternative to appending the contents of the data buffer to the mXML buffer, a pointer may be 
provided to convey this information. This may be usefiol, for example, if the conversion is 
performed as a prerequisite to transmitting the mXML document to another computer. In this 
case, the contents of the mXML buffer can be transmitted first, followed by the contents of the 
data buffer which are located using the pointer.) 



Fig, 7 provides a flowchart which sets forth the logic which may be used to convert an 
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mXML document to an XML document, according to a preferred embodiment of the present 
invention. This logic is similar to that depicted in Fig. 5. (Alternatively, an XML document may 
be composed by processing the mXML content represented in the array-based structure disclosed 
in the first related invention, and simply writing the XML document as these arrays are traversed. 
The manner in which this may be accomphshed is straightforward, as discussed in the first related 
invention.) 

The process of parsing an mXML document and generating its corresponding XML 
document begins at Block 700, by initializing a pointer to a buffer that will be used to construct 
the XML document and a data buffer pointer that points to the beginning of the mXML data 
buffer for the source document. Block 700 also initializes a node pointer that is used to keep 
track of which node specification is currently being processed firom the source mXML document. 

The logic of Blocks 705 through 785 is then iteratively performed to process the node 
specifications fi^om the mXML document and create the corresponding XML representation 
thereof (Preferably, this logic is implemented as re-entrant code which will be recursively 
invoked fi*om Block 780, as discussed below.) 

Block 705 obtains the next node specification fi^om the mXML document, which is found 
by scanning to the next opening parenthesis delimiter, and sets the node pointer to point to this 
specification. Block 710 tests to see if the processing is complete (i.e. if there are no more node 
specifications). When this test has a positive response, the XML document is complete and 
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control transfers to Block 790. At Block 790, the XML document may be processed according 
to the needs of a particular implementation. For example, if an in-memory buffer has been used to 
store the converted document, the buffer contents are preferably written to a persistent storage 
medium. The processing of Fig. 7 then ends. 

5 Control reaches Block 715 when there is another node specification in the mXML 

document to be processed. Block 715 obtains the node name fi^om this node specification, 
beginning fi-om the position following the opening parenthesis deUmiter to the position preceding 
the first semi-colon delimiter (Block 715). Block 720 writes an opening XML tag delimiter 

O 

to the current position in the XML buffer, followed by this node name, and moves the XML 
ii buffer pointer accordingly (i.e. to the next position in the XML buffer). 

^ ' Block 725 then obtains the children list by scanning until reaching the next-successive 

ffl semi-colon delimiter. Block 730 asks whether the children list is empty. If so, control transfers to 

Block 740. Otherwise, the index values of the child nodes fi-om the list in the mXML document 
^ are saved. (Alternatively, the processing of Blocks 725 through 735 may be omitted from this 
15 point in the processing by scanning dir^tly to the attribute list after operation of Block 720, In 

this case, the children list is preferably obtained immediately prior to operation of Block 775, by 

scanning backward in the node specification, thereby avoiding the need to store the index values 

for later u^ and to perform 2 tests as to whether this list is empty.) 



The attribute list is obtained from the node specification at Block 740. 
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The list is checked 



(Block 745) to see if it is empty. If not. Block 750 writes the information for each attribute into 
the XML buffer and moves the buffer pointer. 

Writing each attribute's information preferably comprises writing a blank space to follow 
the node name written out in Block 720. This blank space is then followed by the attribute name, 
5 where the attribute name is found using the starting position and length from the attribute list 
along with the data bxiffer pointer to index into the mXML data buffer, and then (i) an optional 
blank space, (ii) an equal sign, (iii) another optional blank space, and (iv) an opening quotation 
mark. The attribute value is then obtained from the mXML data buffer using the starting position 
and length from the attribute list, along with the data buffer pointer. This attribute value is then 
M written to the XML data buffer, followed by a closing quotation mark. This process is repeated 
52 ft>r each attribute in the attribute list (where each attribute nameA^ake pair is preferably separated 
^ ' from the preceding pair using a blank space), after which processing continues at Block 755. 
m (While the preferred embodiment is described in terms of separating output tokens in the XML 
H document using blank spaces, it will be obvious than other separators may be used equivaiently, 
W such as multiple blank spaces and/or tab character(s) and/or line retum(s).) 

Block 755 writes a closing tag delimiter to the XML output buffer. Block 760 then 
obtains the node's value information from the mXML document. If there was none, the test in 
Block 765 has a negative result, and the processing of Block 770 is bypassed. Otherwise, Block 
770 uses the starting position and length from the node specification, along with the mXML data 
20 buffer pointer, to obtain the actual node value and writes this value to the next position(s) in the 
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XML output buflfer. 



Block 775 then tests whether the previously-stored list of child nodes (from Block 735) is 
empty. If not. Block 780 writes the child nodes to the XML buffer. Preferably, this is performed 
by recursively invoking the logic of Blocks 705 through 785 for each child node, where this child 
node's specification is obtained at Block 705 usmg a simple in-order traversal through the mXML 
document. 

Upon reaching Block 785, all children of the current node have been processed. Block 
785 then writes a closing tag, which has the syntax followed by the node name determined in 
Block 715 followed by ">", to the XML buffer. Control then returns to Block 705 to process the 
next node specification. 

Application programs may also generate mXML documents directly, in which case a 
conversion such as that described herein is not inquired. The technique with which this document 
generation may be accomplished is straightforward in view of the teachings herein. Application 
programs generating XML output typically invoke APIs (Application Programming Interfaces) to 
handle elements of the XML syntax, APIs to create mXML syntax may be substituted, or may be 
vmtten to intercept the existing API calls. Once the invoked code of the API creates the 
appropriate document objects, as is currently provided in the art, a document tree may be 
generated from these objects by adding a root node, attaching the children nodes to their parent 
nodes, and attaching any attributes to their corresponding nodes. This document tree is then 
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preferably traversed in two phases to create an mXML document. First, the tree is traversed to 
(1) obtain the node count; (2) build an mXML data buflfer storing the node values, attribute 
names, and attribute values; and (3) set a pointer to this data buflfer pointer. The tree is then 
traversed again, writing out the structural information for each node specification using the 
techniques described above, followed by writing out the contents of the data buflfer. The resulting 
mXML document may then be stored, processed, etc. 

As has been demonstrated, the present invention provides a compact notation for 
specifying document structure and content, where this notation is a machine-fiiendly alternative to 
XML. This notation has been designed to improve the eflSciency of processing structured 
documents, to reduce the storage requirements for structured documents, and to reduce the time 
required to transmit documents across networks. Studies conducted by the inventors of the 
present invention show that the processing time can be reduced by approximately a factor of 10 
by using this alternative, machine-oriented notation instead of the XML notation of the prior art, 
while still conveying equivdent content and semantic information. 

This machine-oriented notation may be used within a product boundary, enabling (for 
example) mXML documents to be shared among diflferent processing components, transferred 
from one storage medium to another (such as between memory and disk), and so forth. Methods 
of conducting e-commerce or e-business are also fecilitated when documents are encoded in 
mXML, as those documents may be eflSciently exchanged among business partners, wthin 
diflferent locations of an enterprise, etc. 
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While the preferred embodiment of the present invention has been described, additional 
variations and modifications in that embodiment may occur to those skilled in the art once they 
learn of the basic inventive concepts. In particular, the preferred embodiment may be adapted to 
changes in the XML notation, should they occur, and the inventive concepts disclosed herein may 
also be adapted for use with other notations that are syntactically similar to XML. Therefore, it is 
intended that the appended claims shall be construed to include both the preferred embodiment 
and all such variations and modifications as fall within the spirit and scope of the invention. 
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What is claimed: 



1 L A document encoded in an extensible machine-oriented structured notation, wherein the 

2 document resides on one or more computer-readable media and comprises: 

3 a node count representing a count of nodes in the document; 

4 a node specification for each of the nodes, each of the node specifications comprising: 

5 a node name; 

6 a child list specifying index values of zero or more nodes which are children of the 

7 node; 

8 an attribute Ust specifying zero or more (attribute name, attribute value) pair 
S references for attributes of the node; and 

li a node value specification, which is empty if the node has no value; and 

ff a data buffer containing attribute names and attribute values referenced firom the attribute 

ft' hsts and node values referenced fi-om the node value specifications. 



I* 2, The document according to Claim 1, wherein each (attribute name, attribute value) pair 

9 reference specifies a starting name position, a name length, a starting value position, and a value 

3 length, 

1 3 . The document according to Claim 2, wherein the starting name position and starting value 

2 position ^e relative to a beginning of the data buffer. 



4. The document according to Claim 2, wherein the starting name position and starting value 
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position are relative to a beginning of the document. 



1 5. The document according to Claim 1, wherein the node value specification specifies a 

2 starting value position and a value length. 

1 6. The document according to Claim 5, wherein the starting value position is relative to a 

2 beginning of the data buffer. 

1 7. The document according to Claim 5, wherein the starting name position and starting value 
position are relative to a beginning of the document. 

3 8. The document according to Claim 1, wherein each (attribute name, attribute value) pair 
ll reference specifies a starting name position, an ending name position, a starting value position, 
3 and an ending value position. 

Hi 9. The document according to Claim 1, wherein the node value specification specifies a 

2 starting value position and an ending value position. 

1 10. A computer program product embodied on one or more computer-readable media, the 

2 computer program product adapted for encoding a document in an extensible machine-oriented 

3 structured notation and comprising: 

4 computer-readable program code means for encoding a node count representing a count 
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5 of nodes in the document; 

6 computer-readable program code means for encoding a node specification for each of the 

7 nodes, fiirther comprising: 

8 computer-readable program code means for encoding a node name; 

9 computer-readable program code means for encoding a child list specifying index 

10 values of zero or more nodes which are children of the node; 

1 1 computer-readable program code means for encoding an attribute list specifying 

12 zero or more (attribute name, attribute value) pair references for attributes of the node; and 

13 computer-readable program code means for encoding a node value specification, 
l#j which is empty if the node has no value; 

M computer-readable program code means for encoding a data buffer containing attribute 

M names and attribute values referenced fi-om the attribute lists and node values referenced fi-om the 

ff node value specifications; and 

1^: computer-readable program code means for storing the encoded node count, the encoded 

W node specifications, and the encoded data buffer as the encoded document in memory or writing 

M the encoded document to one or more storage media. 

1 11. A computer program product embodied on one or more computer-readable media, the 

2 computer program product adapted for processing a document encoded in an extensible machine- 

3 oriented structured notation and comprising: 

4 computer-readable program code means for parsing the document, fiirther comprising: 

5 computer-readable program code means for parsing a node count representing a 
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6 count of nodes in the document; 

7 computer-readable program code means for parsing a node specification for each 

8 of the nodes, further comprising: 

9 computer-readable program code means for parsing a node name; 

10 computer-readable program code means for parsing a child list specifying 

1 1 index values of zero or more nodes which are children of the node; 

12 computer-readable program code means for parsing an attribute list 

13 specifying zero or more (attribute name, attribute value) pair references for attributes of the node; 

14 and 

15 computer-readable program code means for parsing a node value 
lis specification, which is empty if the node has no value; and 

If computer-readable program code means for parsing a data buffer containing 

0 attribute names and attribute values referenced from the attribute lists and node values referenced 
from the node value specifications; and 

2& computer-readable program code means for using the parsed document as input for the 

O 

2¥ processing, 

1 12. A computer program product embodied on one or more computer-readable media, the 

2 computer program product adapted for converting an input document encoded in an extensible 

3 human-firiendly extensible markup language ("XML") to an output document encoded in a 

4 machine-oriented extensible markup language ("mXML") and comprising: 

5 computer-readable program code means for creating a document tree representation of the 
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6 input document; 

7 computer-readable program code means for obtaining a node count representing a count 

8 of nodes in the document tree representation; 

9 computer-readable program code means for writing the node count to an mXML buffer; 

10 computer-readable program code means for traversing each node in the document tree 

1 1 representation and generating a corresponding node specification in the mXML buffer, fiirther 

12 comprising: 

13 computer-readable program code means for generating a node name; 

14 computer-readable program code means for generating an attribute list specifying 
Ij zero or more (attribute name, attribute value) pair references for attributes of the node; 

lli computer-readable program code means for generating a child list specifying index 

W values of zero or more nodes which are children of the node; and 

iW computer-readable program code means for generating a node value specification, 

Ig which is empty if the node has no value; 

^ computer-readable program code means for generating a data buffer containing attribute 

& names and attribute values referenced fi-om the attribute lists and node values referenced fi-om the 

22 node value specifications; and 

23 computer-readable program code means for appending the data buffer to the mXML 

24 buffer to form the output document. 



1 



2 



13. The computer program product according to Claim 12, wherein the computer-readable 
program code means for generating each (attribute name, attribute value) pair reference fiirther 
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3 comprises computer-readable program code means for generating a starting name position, a 

4 name length, a starting value position, and a value length. 

1 1 4. The computer program product according to Claim 13, wherein the starting name position 

2 and starting value position are relative to a beginning of the data bulffer. 

1 1 5. The computer program product according to Claim 13, wherein the starting name position 

2 and starting value position are relative to a beginning of the output document. 

^ ] 6. The computer program product according to Claim 12, wherein the node value 

p specification specifies a starting value position and a value length, 

T 17. The computer program product according to Claim 1 5, wherein the starting value position 

g is relative to a beginning of the data buffer. 

9 1 8, The computer program product according to Claim 1 5, wherein the starting name position 

2 and starting value position are relative to a beginning of the document. 

1 19. The computer program product according to Claim 12, wherein the computer-readable 

2 program code means for generating each (attribute name, attribute value) pair reference fiirther 

3 comprises computer-readable program code means for generating a starting name position, an 

4 ending name position, a starting value position, and an ending value position. 
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1 20. The computer program product according to Claim 12, wherein the node value 

2 specification specifies a starting value position and an ending value position. 

1 2L A system for encoding a document in an extensible machine-oriented structured notation, 

2 comprising: 

3 means for encoding a node count representing a count of nodes in the document; 

4 means for encoding a node specification for each of the nodes, fiirther comprising: 

5 means for encoding a node name; 

M means for encoding a child list specifying index values of zero or more nodes 

W which are children of the node; 

9 means for encoding an attribute list specifying zero or more (attribute name, 

5 attribute value) pair references for attributes of the node; and 

M means for encoding a node value specification, which is empty if the node has no 

W value; 

W means for encoding a data buffer containing attribute names and attribute values 

13 referenced fi*om the attribute lists and node values referenced firom the node value specifications; 

14 and 

15 means for storing the encoded node count, the encoded node specifications, and the 

16 encoded data buffer as the encoded document in memory or writing the encoded document to one 

17 or more storage media. 
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1 22, A system for processing a document encoded in an extensible machine-oriented structured 

2 notation, comprising: 

3 means for parsing the document, further comprising: 

4 means for parsing a node count representing a count of nodes in the document; 

5 means for parsing a node specification for each of the nodes, further comprising: 

6 means for parsing a node name; 

7 means for parsing a child list specifying index values of zero or more nodes 

8 which are children of the node; 

9 means for parsing an attribute list specifying zero or more (attribute name, 
attribute value) pair references for attributes of the node; and 

101 means for parsing a node value specification, which is empty if the node 

W has no value; and 

if means for parsing a data buffer containing attribute names and attribute values 

l3 referenced from the attribute lists and node values referenced fi'om the node value specifications; 

™»' 

yj 

and 

W means for using the parsed document as input for the processing. 

1 23 . A system for converting an input document encoded in an extensible human-friendly 

2 extensible markup language ("XML") to an output document encoded in a machine-oriented 

3 extensible markup language ("mXML"), comprising: 

4 means for creating a document tree representation of the input document; 

5 means for obtaining a node count representing a count of nodes in the document tree 
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6 representation; 

7 means for writing the node count to an mXML buffer; 

8 means for traversing each node in the document tree representation and generating a 

9 corresponding node specification in the mXML buffer, further comprising: 

1 0 means for generating a node name; 

1 1 means for generating an attribute list specifying zero or more (attribute name, 

12 attribute value) pair references for attributes of the node; 

13 means for generating a child list specifying index values of zero or more nodes 

14 which are children of the node; and 

1^ means for generating a node value specification, which is empty if the node has no 

M value; 

ijf means for generating a data buffer containing attribute names and attribute values 

0 referenced from the attribute lists and node values referenced from the node value specifications; 

W ^d 

J§ means for appending the data buffer to the mXML buffer to form the output document, 

1 24. The system according to Claim 23, wherein the means for generating each (attribute name, 

2 attribute value) pair reference further comprises means for generating a starting name position, a 

3 name length, a starting value position, and a value length. 



1 



2 



25. The system according to Claim 24, wherein the starting name position and starting value 
position are relative to a beginning of the data buffer. 
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1 26, The system according to Claim 24, wherein the starting name position and starting value 

2 position are relative to a beginning of the output document. 

1 27. The system according to Claim 23, wherein the node value specification specifies a 

2 starting value position and a value length. 

1 28. The system according to Claim 26, wherein the starting value position is relative to a 

2 beginning of the data buffer. 

HI 29. The system according to Claim 26, wherein the: starting name position and starting value 

® position are relative to a beginning of the document. 

S 30. The system according to Claim 23, wherein the means for generating each (attribute name, 

a attribute value) pair reference fiirther comprises means for generating a starting name position, an 

9 ending name position, a starting value position, and an ending value position. 

1 31. The system according to Claim 23, wherein the node value specification specifies a 

2 starting value position and an ending value position. 



1 
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32. A method for encoding a document m an extensible machine-oriented structured notation, 
comprising the steps of: 
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3 encodmg a node count representing a count of nodes in the document; 

4 encoding a node specification for each of the nodes, fiirther comprising the steps of 

5 encoding a node name; 

6 encoding a child list specifying index values of zero or more nodes which are 

7 children of the node; 

8 encoding an attribute list specifying zero or more (attribute name, attribute value) 

9 pair references for attributes of the node; and 

10 encoding a node value specification, which is empty if the node has no value; 

1 1 encoding a data buffer containing attribute names and attribute values referenced fi^om the 
M attribute lists and node values referenced fi*om the node value specifications; and 

M storing the encoded node count, the encoded node specifications, and the encoded data 

M buflfer as the encoded document in memory or writing the encoded document to one or more 

1^' storage media. 

It 33 . A method for processing a document encoded in an extensible machine-oriented 

S structured notation, comprising the steps of 

3 parsing the document, fiirther comprising the steps of 

4 parsing a node count representing a count of nodes in the document; 

5 parsing a node specification for each of the nodes, fiirther comprising the steps of 

6 parsing a node name; 

7 parsing a child Kst specifying index values of zero or more nodes which are 

8 children of the node; 
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9 parsing an attribute list specifying zero or more (attribute name, attribute 

10 value) pair references for attributes of the node; and 

1 1 parsing a node value specification, which is empty if the node has no value; 

12 and 

1 3 parsing a data buflPer containing attribute names and attribute values referenced 

14 fi'om the attribute lists and node values referenced from the node value specifications; and 

1 5 using the parsed document as input for the processing, 

1 34. A method for converting an input document encoded in an extensible human-fiiendly 

2 extensible markup language ('"XML") to an output document encoded in a machine-oriented 
ffi extensible markup language ("mXML"), comprising the steps of 

S creating a document tree representation of the input document; 

^ obtaining a node count representing a count of nodes in the document tree representation; 

5 writing the node count to an mXML buffer; 

^ traversing each node in the document tree representation and generating a corresponding 

W node specification in the mXML buffer, fiirther comprising the steps of 

9 generating a node name; 

10 generating an attribute Ust specifying zero or more (attribute name, attribute value) 

1 1 pair references for attributes of the node; 

12 generating a child list specifying index values of zero or more nodes which are 

1 3 children of the node; and 

14 generating a node value specification, which is empty if the node has no vahie; 
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1 5 generating a data buffer containing attribute names and attribute values referenced from 

16 the attribute lists and node values referenced from the node value specifications; and 

1 7 appending the data buffer to the mXML buffer to form the output document. 

1 35. The method according to Claim 34, wherein the step of generating each (attribute name, 

2 attribute value) pair reference further comprises the step of generating a starting name position, a 

3 name length, a starting value position, and a value length. 

1 36. The method according to Claim 35, wherein the starting name position and starting value 

% position are relative to a beginning of the data buffer. 

W 37. The method according to Claim 35, wherein the starting name position and starting value 

^ position are relative to a beginning of the output document. 

Ifc 38. The method according to Claim 34, wherein the node value specification specifies a 

W starting value position and a value length, 

1 39. The method according to Claim 37, wherein the starting value position is relative to a 

2 beginning of the data buffer. 

1 40. The method according to Claim 37, wherein the starting name position and starting value 

2 position are relative to a beginning of the document. 
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41 . The method according to Claim 34, wherein the step of generating each (attribute name, 
attribute value) pair reference fiirther comprises the step of generating a starting name position, an 
ending name position, a starting value position, and an ending value position. 



1 42, The method according to Claim 34, wherein the node value specification specifies a 

2 starting value position and an ending value position. 

1 43. A document encoded in an extensible machine-oriented structured notation, wherein the 

5 document resides on one or more computer-readable media and comprises: 
31 a node count representing a count of nodes in the document; 

9 a node specification for each of the nodes, each of the node specifications comprising: 

^ a node name; 

5 a child list specifying index values of zero or more nodes which are children of the 

S node; and 

W a node value specification, which is empty if the node has no value; and 

9 a data buflFer containing node values referenced fi-om the node value specifications. 

1 44. A method for encoding a document in an extensible machine-oriented structured notation, 

2 comprising the steps of: 

3 encoding a node count representing a count of nodes in the document; 

4 encoding a node specification for each of the nodes, further comprising the steps of 
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5 encoding a node name; 

6 encoding a child list specifying index values of zero or more nodes which are 

7 children of the node; and 

8 encoding a node value specification, which is empty if the node has no value; 

9 encoding a data buffer containing node values referenced fi-om the node value 

10 specifications; and 

1 1 storing the encoded node count, the encoded node specifications, and the encoded data 

12 buffer as the encoded document in memory or writing the encoded document to one or more 

13 storage media. 
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ABSTRACT OF THE DISCLOSURE 

The present invention provides a machine-oriented notation for representation and interchange of 
extensible documents, as well as a method, system, and computer program product for operatmg 
upon (e g, parsing, and storing documents in) this notation. The notation is designed to be 
significantly more compact than the Extensible Markup Language (XML), while still conveying 
the content and semantics of the data and the structure of the document. An existing XML 
document may be converted to this machine-oriented notation, which is referred to herein as 
"'mXML" for "machine-oriented XML". Or, documents may be created directly in mXML as an 
alternative to creation in XML. In the general case, a document represented using the mXML 
notation can be processed much more efficiently than when using the existing human-fiiendly 
XML notation, requires much less storage space, and has a significantly lower transmission cost 
for data interchange. XML documents can be converted to mXML using techniques of the 
present invention. For those cases where it is necessary or desirable for a human to see the 
docimient in the human-fiiendly form (for example, for directly editing the document fi'om its 
source file), a document represented in mXML can be easily converted to XML using techniques 
of the present invention. The novel techniques disclosed herein are also applicable to notations 
other than XML. 
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Declaration and Power of Attorney for 
Patent Application 

As a below named inventor, I hereby declare that: 

My residence, post office address and citizenship are as stated below next to my name; I believe I 
am the original, first and sole inventor (if only one name is listed below) or an original, first and joint 
inventor (if plural names are listed below) of the subject matter which is claimed and for which a 
patent is sought on the invention entitled 

Machine-Oriented Extensible Document Representation and Interchange Notation 

the specification of which (check one) 
I ^ I is attached hereto. 

I I was filed on as Application Serial No. and was amended on 



I hereby state that I have reviewed and understand the contents of the above- identified specification, 
including the claims, as amended by any amendment referred to above, 

I acknowledge the duty to disclose information which is material to the patentability of this application 
in accordance with Title 37, Code of Federal Regulations, §1.56. 

I hereby claim foreign priority benefits under Title 35, United States Code, §119 of any foreign 
application(s) for patent or inventor's certificate listed below and have also identified below any 
foreign application for patent or inventor's certificate having a filing date before that of the application 
on which priority is claimed: 

Prior Foreign Application(s): 

Number Country Day/Month/Year Priority Claimed 



I hereby claim the benefit under Title 35, United States Code, §120 of any United States 
application(s) listed below and, insofar as the subject matter of each of the claims of this application 
is not disclosed in the prior United States application in the manner provided by the first paragraph 
of Title 35, United States Code, §112, 1 acknowledge the duty to disclose information material to the 
patentability of this application as defined in Title 37. Code of Federal Regulations, §1.56 which 
occurred between the filing date of the prior application and the national or PCT international filing 
date of this application: 

Prior U.S. Applications: 

Serial No. Filing Date Status 



I hereby declare that all statements made herein of my own knowledge are true and that all 
statements made on information and belief are believed to be true; and further that these statements 
were made with the knowledge that willful false statements and the like so made are punishable by 
fine or imprisonment, or both, 
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under Section 1001 of Title 18 of the United States Code and that such willful false statements may 
jeopardize the validity of the application or any patent issued thereon. 

As a named inventor, I hereby appoint the following attorneys and/or agents to prosecute this 
application and transact all business in the Patent and Trademark Office connected therewith: 
J. S. Ray-Yarletts, Reg. No. 39,808; B. A. Clay, Reg. No. 32,121 ; G. M. Doudnikoff, Reg. No. 32,847; 
E. H. Duffield, Reg. No. 25,970; J. W. Herndon. Reg. No. 27,901; G. R. Woods, Reg. No. 24,144; 
C. A. Hughes, Reg. No. 26,914; E. A. Pennington, Reg. No. 32,588; J, E. Hoel, Reg. No. 26,279; and 
J. C. Redmond, Jr., Reg. No. 18,753. 

Send all correspondence to: Jeanine S. Ray-Yarletts 

IBM Corp., Dept. T81/Bldg. 062 
P.O. Box 12195 

Research Triangle Park, NC 27709 
Phone: 919-543-2541 Fax: 919-254-4330 
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